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1.0 INTRODUCTION 


The trend over the past decade, in the aeronautics and astronau- 
tics fields, is to provide increasing amounts of synthesized 
data for the human controller of a flight vehicle. One would 
expect this demand to continue on into the future. The major 
impetus for this trend is the continued distribution of computing 
capability to support integrated command and control of flight 
vehicles. This has given rise to the concept of an "operations 
management system". The definition of an operations management 
system, as used in this paper, is "that hardware and/or software 
which is responsible for the integrated operational control of 
aeronautic and astronautic distributed flight systems". This 
reflects the industry trend in avionics system engineering and 
integration (SE&I) toward operationally managing increasing 
amounts of data from an increasing number of sources, interpre- 
ting the data and using it in decision support systems for the 
operator .' This is happening in the commercial and military air- 
craft business as well as in the manned and unmanned spacecraft 
business. When one peruses the literature one finds such titles 
as "vehicle management systems", "flight management systems", 
"cockpit management systems" and "mission management systems". 
They all have in common, the goal of providing an operational 
capability to manage this increasing volume of data without 
overwhelming the pilot, astronaut or automated control system. 

2.0 OBJECTIVES 

The overall objective of an operations management system is to 
provide an orderly and efficient method to operate and maintain 
aerospace vehicles. The purpose of the system is to aid in com- 
manding and controlling the vehicle systems, whether distributed 
or centralized, in an integrated manner. This can be done in 
such a fashion that total vehicle status and response can be 
quickly understood and controlled. An operations management 
system must be built such that it and the other vehicle systems 
can evolve to support a flight program which may last for thirty 
years. For example, a particular automation technique may first 
be used under direct operator control, and later, as confidence 
is gained in the technique it would be allowed to function 
autonomously. Considerable production and operational efficien- 
cies can be achieved by using modular and standardized software 
structures, common user controls, and standardized procedures 
shared by several vehicles. The achievement of commonality of 
design and control for all future aerospace vehicles requires 
continual emphasis in order to achieve significant reduction in 
our budgetary and human resources. 

3.0 OMS PROVIDES THE FRAMEWORK FOR INTEGRATED COMMAND AND CONTROL 

The fundamental philosophy behind the implementation of an opera- 
tions management system is to perform as much processing as pos- 
sible at the lowest architectural levels. This approach facili- 
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tates efficient use of a distributed information systems resour- 
ces and provides the requisite flexibility to support operations 
as procedures change and when new system components are added or 
replaced. A Space Station Freedom (SSF) Operations Management 
System (OMS) is being designed which provides integrated command 
and control through a hierarchical architecture consisting of 
three levels or tiers. The tier structure can be thought of as 
being analogous to a classical business organization. Tier I is 
the high-level executive function. At this global level, general 
operating policies are enacted and enforced. For SSF, the flight 
crew, ground control centers, and OMS constitute Tier I. 

Tier II is the line management, working largely autonomously to 
carry out utility systems and facility level functions and to 
fulfill the global requirements set at Tier I. Constituents of 
this architectural level include the distributed executives for 
systems such as Electrical Power, habitat and laboratory modules, 
and attached payloads. This level offers the possibility of 
accommodating future independent module operations, constrained 
only by the global oversight of Tier I. 

Tier III is where subsystem and component operations and control 
occur. Denizens of Tier III include the so-called "smart" compo- 
nents, equipment racks, and payload groups. During operations, 
Tier III receives compact, concise instructions and commands are 
passed down from Tier I through Tier II. In the course of pas- 
sing through each level, the command is successively "decomposed" 
into specific instructions directed to the appropriate target 
executives and components. Thus, the a terse Tier I instruction 
such as, "Perform a reboost in one hour" spawns hundreds of suc- 
cessor commands that propagate down through Tier III for ultimate 
execution . 

These commands direct tasks such as targeting the burn, configur- 
ing the flight control system to support powered flight, configu- 
ring and verifying readiness of the propellant subsystems and 
securing payloads and experiments so that they can withstand the 
anticipated acceleration. In a corollary fashion, data from the 
lower architectural levels is synthesized as it negotiates its 
way to the top. Tier III components will typically be dealing 
with micro-instructions and data in terms of register contents 
and similar machine-specific constructs. In the case of a SSF 
reboost. Tier III might send a rather detailed accounting of 
their status to Tier II (but still less detailed than what exists 
at Tier III) . What survives of this data when it reaches Tier I 
might be a simple "Go/No Go" statement of system readiness. This 
hierarchical approach to operations management, monitoring, com- 
mand and control maximizes the efficiency of data processing and 
communications resources. The multi-tiered structure optimizes 
the interface at each level. Thus Tier I transactions are inher- 
ently amenable to the natural language constructs of the User 
Interface Language (UIL) , while the machine-specific instructions 
at Tier III are best handled by the components at that level. 
Localizing the man-machine interface to a single architectural 
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level produces significant gains in human productivity while 
lowering training requirements and reducing exposure to procedu- 
ral misunderstandings. 

4.0 TECHNOLOGY ISSUES 

Greater efficiency in the development and maintenance of aeros- 
pace vehicles utilizing operations management system approaches, 
requires meeting specific technological goals. These goals 
include advances in software development techniques and computer 
hardware capabilities. 

Sound software engineering techniques need to be developed to 
allow production of code that is flexible, easy to share among 
diverse applications and inexpensive to build and maintain 
throughout its life cycle. An advanced software engineering 
development environment will increase the efficiency of code pro- 
duction, much like the use of spreadsheet programs increases the 
efficiency of financial and engineering calculations. Increased 
efficiency of code generation can be achieved through the use of 
expert systems-based tools that optimize software structures and 
aid the engineer in assembling applications from libraries of 
component software parts. Strong systems engineering, at the 
beginning of a program, can produce software products that are 
useful for a host of applications across other aerospace 
programs . 

Standards for computer hardware need to be developed along with 
computers capable of interacting with other computers in an hete- 
rogeneous environment of hardware types and multiple software 
languages. Experience has shown that, despite the existence and 
use of standards, there is always a need for heterogeneity. 

Experience with the use of expert systems and other advanced 
automation software techniques needs to be widened to the extent 
that enough engineering confidence is gained with them so that 
they will be utilized for command and control. Methods need to 
be developed to harness these techniques to achieve increasingly 
effective and efficient interactions between man and machine and 
interactions among machines. An increased emphasis is required on 
making these command and control interactions generic enough to 
be valid and useful across a variety of future aerospace vehicles 
and for upgrades to present vehicles. 

5.0 RECENT DEVELOPMENTS IN OMS COMPONENTS 

A conceptual architecture design activity for the integrated com- 
manding of hierarchical distributed systems began at the NASA JSC 
in 1985 as a study for the Mission Operations Directorate 
(JSC 20792) . This study provided the basis for the SSF onboard 
portion of the OMS. The final phases of this study coincided with 
the beginning of the OMS Working Group, which first met in early 
1986 and provides the forum for discussions and dissemination of 
information related to design and implementation of the SSF OMS. 
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Standalone component prototypes were developed in Zeta Lisp on 
the Symbolics. A Procedures Interpreter (PI) component illustra- 
ted the use of different levels of automation in the execution 
and monitor of crew procedures. An Integrated Status Assessment 
(ISA) component performs failure analysis based on integrated 
models of the SSF utility systems. These components were first 
demonstrated in October 1986. 

For other NASA programs several expert system based components 
have been developed and are in use to perform intelligent monitor 
and diagnosis of manned and unmanned systems operations. The 
Integrated Communications Officer (INCO) Expert System has been 
installed in the Mission Control at JSC, and is used by flight 
controllers during Naational Space Transportation System (NSTS) 
operations to perform automated monitoring of the communications 
equipment. The success of INCO has resulted in a number of simi- 
lar projects that incorporate advanced automation in other flight 
control positions in Mission Control. Similarly, the Spacecraft 
Health Automated Reasoning Prototype (SHARP) is used at the Jet 
Propulsion Laboratory to perform automated health and status ana- 
lysis. They are using SHARP for multi-mission spacecraft and 
ground data systems operations, with its initial focus being on 
the telecommunications link of the Voyager II spacecraft. Ano- 
ther application, that began as a proof-of-concept prototype and 
is finding use in operations, is the Maintenance Operations Mana- 
gement System (MOMS) . MOMS uses advanced graphics and video tech- 
niques to assist in the execution of onboard maintenance procedu- 
res. MOMS is currently being installed in the Mission Support 
Room at JSC for use on the NSTS. Other expert system prototypes 
are also in development in the areas of flight plan generation 
and replanning and in fault diagnostics. 

6.0 MAJOR ACCOMPLISHMENTS IN OVERALL SYSTEM DESIGNS 

An operations management system represents the highest level of 
control in any hierarchical distributed environment. Space Sta- 
tion Freedom represents one such environment, although there are 
other examples, such as the command and control of deep space 
probes. Aspects of technology that are used in an operations 
management system include system health analysis, command and 
control, and plan generation and execution. An operations mana- 
gement system involves not only the real time aspect of opera- 
tions, but also the support activities that make it possible to 
use advanced automation in real time control. 

The SSF OMS Integration Group, at the Johnson Space Center (JSC) 
was formed in September 1987 to organize the effort to integrate 
prototype OMS software with other SSF system simulations. The OMS 
Integration efforts primary goal was to demonstrate an OMS inte- 
grated command and control architecture. This has been demon- 
strated in a phased manner, with the OMS prototype commanding 
a Guidance, Navigation and Control simulation with respect to 
global commands ("start the reboost"), while GN&C performs system 
specific functions ("turn on jet 2"). The OMS prototype coordina- 
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tes appropriate global activities ("prepare all systems for 
reboost") . Phase Two, currently in test, saw the migration of 
the OMS prototypes from a Symbolics to a VAX computing environ- 
ment, and the addition of more functions and simulations. Thermal 
Control, Communications and Tracking, Electrical Power have been 
added to the original reboost scenario along with a SUN hosted 
node representing the ground control segment of the OMS. Also 
added was a VAX-based Display and Control node representing the 
displays a crewperson would use when interacting with the OMS. 

Future demonstrations have been planned that add more simulation 
nodes, especially for payloads, and add functions to the OMS node, 
extending both horizontal and vertical integration. This work has 
been planned through 1991. The additional OMS functions include 
the handling of the onboard short term plan, additional failure 
diagnosis, and contingency replanning functions. Other operatio- 
nal concepts involving an OMS are being studied such as the han- 
ding off of control between a onboard based OMS and a comparable 
ground based system. 

The scope of the work addressed by the OMS Integration Group 
will expand beyond the single SSF manned base in efforts past the 
1991 time frame. For example, the use of the OMS to coordinate 
SSF and NSTS joint operations will be investigated where Test Bed 
nodes represent involved systems and trajectory dynamics. Even- 
tually, the effort will migrate to a computing environment that 
is more flight-like by using prototype onboard hardware at the 
representative nodes and executing flight type applications soft- 
ware . 

7.0 SIGNIFICANT FUTURE MILESTONES 

Figure 1 (Key Technologies For OMS Future Development), shows two 
technology areas, Expert Systems and Man-Machine Interfaces, 
which are key to the future development of an OMS. In addition, 
this figure identifies the new NASA programs which could benefit 
from these technologies. Advancement of the technology is divided 
into three areas of sponsorship; Research & Technology (R&T) , 
Advanced Development and program level Design, Development, Test 
& Evaluation (DDT&E) . The sponsor for each of these areas would 
carry the technology development through some level of completen- 
ess. These completeness levels, as defined by the Office of Aero- 
nautics and Space Technology (OAST) , are identified in the table 
below. 


DDT&E 

Level 7 

Engineering Model in Space 

Advanced 

Development 

Level 6 
Level 5 

Prototype/Engineering Model Tested 
Component /Brassboard Tested in 
Relevant Environment 


Level 4 

Critical Function/Characteristic 


Demonstration 
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R&T 


Level 3 


Designs Tested Analytically or 
Experimentally 
Level 2 Conceptual Design Formulated 

Level 1 Basic Principles Understood 


Each of the technologies in Figure 1 would be applied to funda- 
mental operations management tasks ( i.e. f planning, diagnosis or 
system control) which are performed by the system to assist the 
human operators . The expert systems technology for control of 
complex dynamic subsystems will evolve from control of single 
sub-systems in the early Space Station era to hierarchical con- 
trol of multiple sub-systems later, and to distributed control of 
many subsystems in the Mars Transfer Vehicles. As the expert 
system capabilities evolves, and as confidence increases, less 
human interaction and monitoring of the system will be requi- 
red. This will free-up onboard crewperson time and reduce the 
number of ground support people. Man-Machine Interface (MMI) 
development must parallel the evolution of the expert system 
technology. Even though an automated capability may be control- 
ling, the user must be provided with sufficient information to 
assess the state of the system and be allowed the option of man- 
ual override at any time without delay. The essence of the MMI is 
to permit the system to smoothly transition between operator 
control and automated control. 

Expert Systems for monitoring and control of space hardware has 
been under development for several years at NASA centers. An 
important subset of this technology will be Fault Detection, 
Identification and Reconfiguration (FDIR) for flight hardware. 

The Ames Research Center (ARC) and the JSC, as part of the R&T 
base, have jointly developed a thermal control hardware expert 
system called TEXSYS. They are also formulating an electrical 
power Control expert system called PMACS. Later systems will 
combine individual subsystem controllers into multi-subsystem 
monitors which will allow coordinated control of an entire com- 
plex of space hardware. The Integrated Status Assessment (ISA) 
tool which is part of the SSF OMS integrated test bed at the JSC 
is an example of a global level expert system. Another major 
application of expert system technology is in the space mission 
planning and scheduling. In previous space programs, planning and 
scheduling was a manual task requiring a considerable staff of 
highly specialized people. Today, sophisticated software systems 
are being applied to the planning and scheduling tasks, but they 
are more of an aid to the planners rather than a substitute. 
Future systems will contain the added capability to recommend and 
suggest options and produce a conflict free mission plan contain- 
ing a multitude of activities and constraint parameters. Work is 
underway at the GSFC and at the JSC, using the R&T base, to deve- 
lop expert planning systems. The GSFC is currently performing 
proof-of-concept testing on a planning system called the Schedu- 
ling Concepts, Architecture and Networks (SCAN), for NASA operated 
free flyer space platforms. 
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Procedures and checklists have always played an important role in 
the operation of aeronautical and astronautic systems. For future 
systems, these procedures will still exist, but in a different 
form. For SSF and other new manned flight systems, the procedures 
will be in executable electronic form, permitting execution to be 
accomplished in a near manual step-by-step process, in a semi- 
automatic process where the computer and operator share in the 
execution of sequential steps, or fully automated where the oper- 
ator gives permission for the computer to execute the procedure 
and the operator monitors. Prototypes of these procedure execu- 
tors are being developed at the JSC for SSF as part of the SSF 
OMS integrated testbed activities under the SSF DDT&E. Systems 
currently in development use conventional keyboard and mouse 
devices for manual interaction. Future systems will use natural 
language interfaces and utilize higher level input devices such 
as voice recognition systems. 

Development work underway within the NASA to produce advanced 
man-machine interfaces include the Operations and Science 
Instrument Support (OASIS) command and control system software 
created at the University of Colorado at Boulder Laboratory for 
Atmospheric and Space Physics (LASP) . This system was originally 
created for remotely controlling the Solar Mesophere Explorer 
(SME) which was an earth-observing satellite that measured 
parameters related to ozone levels in the atmosphere. OASIS is 
now being used as the basic MMI structure for SSF OMS prototype 
development . 

8.0 SUMMARY 

This paper has described concepts for an operations management 
system and has highlighted the key technologies which will be 
required if we are to bring this capability to fruition. Without 
this automation and decision aiding capability, the growing com- 
plexity of avionics will result in an unmanageable workload for 
the operator, ultimately threatening mission success or surviva- 
bility of the aircraft or space system. The key technologies 
include expert system application to operational tasks such as 
replanning, equipment diagnostics and checkout, global system 
management, and advanced man-machine interfaces. The economical 
development of operations management systems, which are largely 
software, will require advancements in other technological areas 
such as software engineering and computer hardware. Also, added 
emphasis on systems engineering and integration, early in the 
design phase, will result in systems which are flexible and 
expandable. Accomplishment of the above technological tasks con- 
sists primarily of emphasizing and strengthening existing 
efforts. Some basic research and development is ongoing in each 
of the areas identified. What is missing, is a focus and unified 
effort to apply these technologies to the operations management 
system problem. 
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FIGURE 1 KEY TECHNOLOGIES FOR OMS FUTURE DEVELOPMENT 




